1. Field of the Invention
This invention relates to risk management in large-scale development projects, and more specifically to a web-based risk management tool and method for capturing, assessing, and prioritizing risks and implementing mitigation plans to more effectively manage risk.
2. Description of the Related Art
Due to the level of complexity of multi-million and even billion dollar programs such as the design, development and production of next generation weapon systems, aircraft or spacecraft, delivery of the product on time, within budget and with a high degree of quality assurance is a formidable task.
A typical risk management process 10 incorporates a number of different tools to identify, assess, mitigate and track risk as illustrated in FIG. 1. In the initial phase, project management defines a Risk Management Plan detailing their approach for conducting risk management for the specific project based on customer requirements 12 such as technical specifications, cost and schedule (step 14). The plan outlines how risks will be identified and assessed, how mitigation plans will be developed, how risks will be tracked and what tools and methods will be used. A program risk manager is tasked with implementing the plan and overseeing the risk management portion of the project.
The first step is for each engineer to identify risks that may be associated with each of their tasks (step 16). To assist in this process, each engineer has a risk management tool such as Risk Radar on his or her own PC. The engineer may rely on his or her knowledge and experience, discussions with other engineers and a tool called Technical Risk Identification and Mitigation System (TRIMS), which is mainly used to identify process risks when a program is transitioning between phases such as development to production. The identified risks are then input into the risk management tool's local database on the PC. The engineer may be required to submit the identified risks to the program risk manager for consideration by the risk review board.
To assess the risks (step 18), the engineer refers to a probability of occurrence table 20 of the type shown in FIG. 2 and based on his or her own knowledge and experience rates the probability of failure for a task occurring to be, for example, remote, unlikely, likely, highly likely or near certainty. These labels are then mapped to probabilities Pf and stored in the risk management tool. The selection of Pf is highly subjective based on the engineer's experience, interpretation of the task and interpretation of the labels. Next, the engineer refers to a severity of occurrence table 22 of the type shown in FIG. 3 and selects the impacts 0, 1, 2, 3, 4, or 5 of failure on the basis of technical, schedule and cost impacts, which are also stored in the tool. The cost impact is specified as a percentage of the cost. Schedule impact is oftentimes specified as a percent slippage of a key milestone or, as shown in this case, in general terms of effect on key milestones. The tool calculates a risk factor Rf as the product of the probability of occurrence Pf and the largest impact. The risk factors are then prioritized as, for example, low, moderate and high based on thresholding rules set by the risk management plan and stored in the local database. The priority of the risk factors determines which risk receives special attention and resources and which will not and thus the accuracy and consistency with which they are determined is critical. In the current approach, the risk factors are highly subjective and dependent on the knowledge and expertise of the individual engineer. To accommodate any risk on any project, the Pf and Cf tables are very general. At this point, the engineer may be required to submit a report on the assessed risks to the program risk manager for consideration by the risk review board or may proceed directly to the development of risk mitigation plans. The risk manager maintains a master database of the aggregated reports from each engineer or team, monitors progress and reports back through risk review meetings on the status of risk mitigation.
To develop a risk mitigation plan (step 24), the engineer first refers to the risk assessment to determine the priority of the risk. A risk with a high risk assessment is expected to receive more resources for mitigation. In most cases, the engineer proposes a mitigation plan based on his or her knowledge and experience and submits the plan to the program risk manager for consideration by the risk review board. The board must consider all the program risk factors based on the risk factors and mitigation plans created independently by each engineer and, as constrained by available resources, make critical decisions on the mitigation plans to be funded and implemented. The board's decisions are only as good as the risk factors and plans provided.
At this point, the identified risks, risk factors and accepted mitigation plans form an initial input to the integrated master plan that is the initial input to a program master schedule. A tool such as Microsoft Project is used to create a detailed schedule that links all the tasks and sub-tasks and mitigation plans together. As the project progresses, the engineers and managers continually update MS Project to track achieved milestones, slippage and reasons for revision. The progress information and trends from MS Project are forwarded to the risk manager to track and report risks (step 26) and analyze the information to determine whether new risks should be identified.
Based on the current status, the engineer updates the risk and mitigation plan status and submits the updates to the project risk manager (step 28). If risks are successfully mitigated and the milestones achieved, the risks are closed (step 30). If a risk changes, the engineer reassesses the probability of occurrence and impact (step 18), makes required adjustments to the mitigation plan and drafts a program plan adjustment report that is submitted to the project manager (step 32). In some cases, a Monte Carlo simulation such as Risk Plus is run on the schedule based on the most optimistic and pessimistic milestone dates and generates additional scheduling risks that should be considered. If a new risk or task appears, the engineer identifies the risk (step 16) and repeats the process. If the scope of the project changes, the process returns to the initial phase for reconsideration of the risk management plan (step 14).
The standard risk management process both in determining an initial or baseline risk mitigation plan and in monitoring ongoing risks is highly subjective and based on the knowledge, experience and decision making capability of many engineers acting independently and in relative isolation to identify risks, determine the risk factors Rf and the development of mitigation plans. The Pf and Cf tables on which the engineers base their assessments are generalized to accommodate any program and any risk. Furthermore, the process is highly bureaucratic in that engineers must prepare and submit multiple reports with very similar information for consideration by the review board.
U.S. Pat. No. 6,397,202 to Robert Higgens entitled “System and Method for Monitoring Risk in a System Development Program” has proposed a technique for an automated expert system to quantify various types of ongoing risk. The system defines a plurality of metrics such as requirements, staffing and source lines of code (SLOC) that relate to the successful completion of the project and projects a baseline for each metric. The system collects data for each metric over a period of time, compares the measured data to the baseline and assigns a risk based on the percentage the measured value deviates from the baseline. The metrics may be weighted to define the relative importance of the data measurements. When the project risk becomes sufficiently high, the program manager is alerted to the problem and can take measures to diminish the risk.
Higgens relies on logical statements, algorithms, and the like, provided by experts who are knowledgeable in analyzing this type of data to determine an output risk level. The expert's rationale is, in effect, captured and stored with the rule-based system. Although a fully-automated expert system has obvious appeal, practice has shown that one size fits all systems that remove all human judgment are rarely effective, the risks encountered do not fit into predefined categories and are more complex than can be adequately handled by if-then type rules. Furthermore, Higgens assumes some baseline and then provides a system for monitoring the ongoing risks relative to that baseline and reacting to them.
There remains an acute and present need to provide a risk management tool and method that is applicable to a wide range of projects but tailorable to a specific project, provides a better technique for assessing and mitigating risks to anticipate and minimize risks, and streamlines the risk management process.